home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / lang / c++-part2 / 11476 < prev    next >
Encoding:
Text File  |  1996-08-05  |  1.4 KB  |  46 lines
  1. Path: nyx10.cs.du.edu!not-for-mail
  2. From: vputz@nyx10.cs.du.edu (Victor Putz)
  3. Newsgroups: comp.lang.c++
  4. Subject: Interface/Class design-- guidelines?
  5. Date: 14 Mar 1996 12:21:23 -0700
  6. Organization: University of Denver, Math/CS Dept.
  7. Message-ID: <4i9rjj$t2a@nyx10.cs.du.edu>
  8. NNTP-Posting-Host: nyx10.nyx.net
  9. X-Newsreader: NN version 6.5.0 #3 (NOV)
  10.  
  11. After flailing with C++ for some time, I'm slowly beginning to
  12. appreciate the benefit of good design (some lessons are slow to
  13. take).  In any case, I feel certain that my "try it and see"
  14. approach to class design is flawed and was wondering if anyone
  15. had any pointers to good class/interface design.
  16.  
  17. I was also intrigued by the bit in "The C++ Programming Language"
  18. (Stroustrop section 12.4, "Interfaces and implementations") wherein
  19. Stroustrop asserts that a class X :
  20.  
  21. class X {
  22.   Y a;
  23.   Z b;
  24. ...
  25. };
  26.  
  27. has problems because "The interface uses the types Y and Z in a way
  28. that requires the declarations of Y and Z to be known to compile it,"
  29. and seems to advocate pointer or reference members as a "better choice"
  30. for significant classes:
  31.  
  32. class X {
  33.   Y* a;
  34.   Z& b;
  35. ...
  36. };
  37.  
  38. ... since the compiler doesn't have to know much about the class to
  39. reserve space for a pointer or reference.  I'm pretty clear how a
  40. pointer member could be used for the same effect (allocate it in the
  41. constructor, don't touch it elsewhere, and deallocate it in the
  42. destructor) but how could a reference member be useful?
  43.  
  44. Thanks-->VPutz
  45.  
  46.